home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19981211-19990422
/
000323_news@watsun.cc.columbia.edu _Sat Mar 6 18:34:52 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-04-21
|
4KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA20208
for <kermit.misc@watsun.cc.columbia.edu>; Sat, 6 Mar 1999 18:34:51 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA15158
for kermit.misc@watsun.cc.columbia.edu; Sat, 6 Mar 1999 18:31:29 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: kermit messages
Date: 6 Mar 1999 23:31:28 GMT
Organization: Columbia University
Message-ID: <7bsdsg$epk$1@newsmaster.cc.columbia.edu>
To: kermit.misc@mailrelay2.cc.columbia.edu
In article <y93ogm6mcry.fsf@zohar.ai.mit.edu>,
Allan Adler <ara@zohar.ai.mit.edu> wrote:
:
: I am running kermit on a 80486 under RedHat 5.1 Linux. In downloading
: files, I frequently get messages about input overruns. I gather that
: this is a correctable error since the integrity of the file seems
: uncompromised after the file is downloaded.
:
This means either:
(a) You do not have an adequate flow-control method enabled between
C-Kermit and the modem. If, however, you are using C-Kermit 6.0 or
later with a modern modem, and following the instructions for
dialing, then Kermit should be choosing RTS/CTS by default, and
also setting it in the modem. Or:
(b) Your serial port is an unbuffered kind (8250, 16450, etc) rather
than a buffered one, in which case the Linux device driver itself
loses characters when its attempt to flow control the modem are
not fast enough. Or:
(c) You have interrupt conflicts in your PC configuration.
The Kermit protocol is designed to correct errors like this, and it's
doing its job in your case.
: Today I started getting
: a new message in addition to the overrun message. It is:
:
: ll_rw_block: device 03:02: only 1024-char blocks implemented (4096)
:
: Again, it doesn't seem to have compromised the integrity of the file
: transferred. However, if these messages indicate that I should be
: doing something differently I would like to know about it. It would
: also be nice to know what they mean; I'm clueless.
:
: The file that gave the new message was a compressed tar file. When
: I left kermit and tried to uncompress the file, I got the same
: message:
:
: ll_rw_block: device 03:02: only 1024-char blocks implemented (4096)
:
: So maybe something else is going on, not specifically involving kermit.
:
Which version of C-Kermit are you using? Newer versions do bigger disk
writes. Version 7.0 might try to write anywhere from 4K to 32K at a time.
Evidently your disk device driver doesn't handle large writes "atomically"
and therefore puts up a warning message to let you know this. But from what
you said, it also appears to recover from them by breaking large writes up
into smaller ones internally.
In C-Kermit 7.0 you can control the size of the disk output buffer with:
SET FILE OUTPUT { { BUFFERED, UNBUFFERED } [ size ], BLOCKING, NONBLOCKING }
Lets you control the disk output buffer for incoming files. Buffered
blocking writes are normal. Nonblocking writes might be faster on some
systems but might also be risky, depending on the underlying file service.
Unbuffered writes might be useful in critical applications to ensure that
cached disk writes are not lost in a crash, but will probably also be
slower. The optional size parameter after BUFFERED or UNBUFFERED lets you
change the disk output buffer size; this might make a difference in
performance.
Please report results back to kermit-support@columbia.edu.
- Frank